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Elevar ficheros Dem 
con POV 


Por estas páginas ya han pasado diversas utilidades de alzado de 


terrenos (la última fue Hf-lab). Todas estas herramientas producen 
objetos de apariencia montañosa utilizando técnicas fractales. Pero, ¿qué 
hacer si uno está interesado en incluir zonas “reales” en una escena? La 
respuesta a esto son los ficheros .Dem (Digital Elevation Model), que 
guardan datos de alturas de zonas terrestres reales y pueden —mediante 


utilidades— ser “traducidos” a archivos tga procesables por «POV». 


l usuario puede en- 
contrar — ficheros 
.dem en muchos si- 
tios, pero sin duda 
el más importante 
es el Web del USGS 
(United States Geological Survey); un 
organismo a través del cual pueden 
conseguirse más de 700.000 fotos aé- 
reas de nuestro planeta. Podemos co- 
menzar en: http:/finfo.er.usgs.gov 
..-y podemos buscar mapas en: 
ftp://edeftp.cr.usgs.gov/pub/data 
Otro “site” muy útil es: www.ems.uw- 
platt.edu/ce/facidymond/giswww.htm 


En este último lugar encontraremos 
una colección de sitios Gis recopilados 
por un tal R. Diamond. (las siglas Gis 
corresponden a “Geographic Informa- 
tion System” y aluden a un sistema de 
información diseñado para tratar infor- 
máticamente coordenadas geográficas. 
Sin embargo, en el faq gis-faq.txt que 
incluimos en el CD-ROM- se indican 
un montón de definiciones más de las 
que parece desprenderse, que GIS es 
tanto una serie de bases de datos como 
un conjunto de procedimientos y nor- 
mativas para procesar estos datos). 

Pero volviendo al Usgs. este orga- 
nismo tiene archivos «dem que cubren 
la totalidad del continente americano 
con una resolución de un valor de altu- 
ra para cada 30 metros. Pero partiendo 
de estas direcciones, podemos hallar fi- 
cheros dem que cubren todas las zonas 
planetarias, información geológica, uti- 
lidades relacionadas cun los datos ofre- 
cidos, bitmaps de otros planetas del sis- 
tema solar y muchas cosas más. 

En cuanto a la palabra dem, es em- 
pleada en muchos sitios como un tér- 


mino genérico que alude a todos los ti- 
pos de ficheros donde se almacenan da- 
tos de elevaciones de zonas geográfi- 
cas. Sin embargo, aquí lo emplearemos 
para referenciar a los ficheros de for- 
mato dem distribuidos por el Usgs. 
Los archivos dem están en formato 
ascii y son arrays de datos donde se 
guardan valores de altitud para distan- 
cias espactales regulares de zonas geo- 
gráficas reales. (es decir, los satélites 
aplican una rejilla imagmaria sobre el 
terreno y toman un valor de altura para 
cada intersección de esta rejilla). La 
pregunta ahora es: ¿cómo podemos 
emplear un archivo .dem desde POV? 


Dem2pov 


Dem2pov es una utilidad escrita por 
Bill Kirby partiendo de otra utilidad de 


conversión más general. Dem2pov lee 
ficheros .dem y produce archivos en for- 
mato tga que podrán ser leídos y emple- 
ados por la sentencia Heightfield de Pov. 
El programa funciona bajo DOS y re- 
quiere al menos un 386. La invocación 
más corriente para este programa es: 

dem2pov fichero_entrada.dem fi- 
chero_salida.tga 


Sin embargo. antes de generar el fi- 
chero tga que emplearemos más tarde 
desde POV, Dem2pov nos hará una se- 
rie de preguntas cuyas respuestas afec- 
tarán al archivo a producir. Para estas 
respuestas podremos apoyarnos en una 
serie de datos que forman parte de la 
cabecera del dem y que Dem2pov m- 
primirá en el monitor antes de formular 
las preguntas. También. si lo deseamos, 
podremos ordenarle al programa que se 
limite a mostrarnos dicha cabecera. sin 
generar ninguna tga (para ello le mdi- 
caremos tan sólo el fichero .dem de en- 
trada). Además, es posible guardar esta 
cabecera en un archivo con una opera- 
ción de redirección de ficheros como: 

dem2pov fichero_entrada.dem > 
fichero_datos.txt 


Pero regresemos al caso más típico. 
Después de mostrarnos los datos de la 
cabecera, el programa nos mostrará el 
mensaje “0 for all, 1 for samples, 2 for 
subset”. Con ello el programa nos ofre- 
ce tres alternativas: si respondemos 
“0”, Dem2pov entenderá que desea- 
mos emplear todos los valores de altu- 
ras del dem. (Este es el caso más fre- 


E 


cuente). Con el programa creará 
una tga “a escala” tomando sólo uno de 
cada x valores de altitud. Este escalado 


no tiene por qué ser proporcionado ya 


as 


A 


que, si escogemos esta op- 
ción, después se nos pedirá 
que mtroduzcamos el “colum 
sample interval” y el “row 
sample mterval”. Es decir, los 
intervalos para las columnas 
y las filas. Si damos un valor 
de 5 para ambos casos, por 
ejemplo, el programa sólo 
tendrá en cuenta un valor de 
altura de cada 5. lo cual quiere decir 
que la tga resultante será 25 veces más 
pequeña. Finalmente, el caso 2 se em- 
plea para crear una tga usando sólo una 
parte del dem y desechando el resto de 
los datos de altitud. Aquí se hace preci- 
so explicar que los datos de alturas del 
dem se ordenan en columnas y filas, 
empezando la primera columna en el 
borde oeste del mapa y la última en el 
lado este. Dentro de cada columna los 
datos empiezan en el Sur del mapa y 
acaban en el Norte. Sabiendo esto po- 
dremos especificar el área del dem a 
partir de la cual va a crearse la tga dan- 
do valores a las siguientes líneas; "start 
column” (primera columna). “end co- 
lumn” (última columna), “start row” 
(primera fila) y “end row” (última fila). 

En la siguiente pregunta el progra- 
ma nos pedirá que indiquemos el tipo 
de heightfield a crear. Los valores acep- 
tables son O para los “Actual heights” y 
1 para los “Normalized”. Si nos decidi- 
mos por el primer caso, el programa 
nos pedirá después (con “vertical sca- 
ling factor”) un valor que será emplea- 
do como factor de conversión entre 
unidades de medida (por ejemplo usa- 
ríamos 3.281 para pasar de metros a 
pies). En el otro caso, la cuestión es al- 
go más complicada: la cabecera del 
Dem devuelve dos valores que son los 
valores de mínima y máxima altitud del 
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fichero. Si escogemos el heightfield 
“normalizado” el valor máximo de alti- 
tud quedará a la altura 1 en el height- 
field de POV (si no se hacen “scales”). 
El resto de los puntos a calcular toma- 
rán sus valores de altitud teniendo en 
cuenta el siguiente factor: 

factor= 65535 / (Elevación 
maxima + Bias) 


El valor 65535 es el número de gra- 
daciones de altura posibles que permi- 
ten los heightfields que emplean tgas. 
La variable “Bras” será la siguiente que 
daremos por teclado. Se trata de un va- 
lor que se sumará o restará a los valores 
de altitud dependiendo de su signo. Pa- 
ra comprender cómo funciona esto 
consideremos los siguientes ejemplos 
tomados del fichero Kirkland.dem (que 
se incluye con la 
utilidad): el valor 
de altitud mínima 
de este fichero es 
de 1158 metros y 
el de la máxima 
de 1820 metros. 
Sy generamos la 
tga escogiendo la 
opción de norma- 
lización y dando 
un valor de O para 
la escala y el Bras, 
el valor de altura 


para el punto más bajo será 
de 0.6326 y de 1.0 para el 
punto más alto. Si, en vez de 
esto, damos un valor de -1158 
al bias, entonces los resulta- 
dos serán de O y de 1 respecti- 
vamente para la altitud de los 
puntos más bajo y más alto. 
Esto quiere decir, por supues- 
to, que, como podemos ver en 
las fotos hftest3 y hftest4 (págima ante- 
rior). la forma fmal del objeto se verá 
afectada. La base del objeto queda en 
el mismo sitio para ambas pruebas pe- 
ro. en el caso del bias=-1158, parece 
que el objeto se ha estirado hacia abajo. 

Finalmente, el programa nos pedirá 
el valor de “default elevation (fmal out- 
put units)”. Nosotros no acabamos de 
comprender la función de este paráme- 
tro. Según el doctorial se emplea para 
dar valores de altitud a los puntos del 
Heightfield para los que no haya valo- 
res dem (¿?). En las pruebas se ha deja- 
do siempre a 0. 


Los ficheros de ejemplo 

Al descomprimir Dem2pov.zip. nos 
encontraremos el ejecutable de la utili- 
dad, el código fuente (dem2pov.c), va- 
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pe 


rios ficheros utilizados para compilar 
dichos fuentes en distintos compilado- 
res, un fichero .pov para hacer pruebas 
(hftest.pov) y un zip con un archivo 
dem de ejemplo (kirland.zip). Como 
veremos, una de las líneas del fichero 
-pov escala el objeto hesghtfield que se 
creará. Este detalle tendrá la virtud de 
dar distintas proporciones al objeto, 
con lo cual quedará alterado el propó- 
sito micial de renderizar un trozo de te- 
rreno real. ¿Por qué? Sy los lectores 
quieren generar terrenos iguales a los 
almacenados en los archivos dem, la 
escala tendrá que ser uniforme en los 
tres ejes (Nota: estamos dando por sen- 
tado que conocéis perfectamente el 
funcionamiento correspondiente a la 
sentencia Height_field de POV; si este 
no es el caso puede hallarse una des- 
cripción de la misma en el artículo 
“Cómo crear terrenos...” del número 8 
de Rendermanía). 


El problema de la textura 
Quizá el problema más importante 
que presenta cualquier Hesghtfield es 
el de la textura a aplicar. Sy nos limita- 
mos a dar un color liso al objeto, este 
no tendrá una apariencia demastado 
real. Las montañas del planeta tierra no 
suelen exhibir un color uniforme. Pe- 


ro, afortunadamente, la realidad puede” 


simularse aplicando un mapa de colo- 
res sobre el objete (como recordarán 
los povmaníacos, la sentencia co- 
lor_map nos permitirá defimir una gra- 
dación suave de colores sobre un obje- 
to). Sin embargo. esto ny será fácil. 
Primero habrá que definir un buen ma- 
pa de colores y luego habrá que apli- 
carlo adecuadamente (podemos ver lo 
que sucede si el objeto está desplazado 
o incorrectamente escalado con respec- 
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to al mapa de co- 
lor mirando las 
imágenes hftest3 
y hftest4). 


Las 
montañas de 
Bryan Beaty 

Bryan Beaty es 
un  pov-usuario 
que suele utilizar ficheros dem para ge- 
nerar estupendas imágenes sintéticas. 
Hay que destacar, sin embargo, que 
una buena parte de ellas no están he- 
chas con POV. sino con utilidades crea- 
das por el propio Beaty. En efecto. este 
autor ha creado una serie de utilidades 
para manipular los archivos dem de di- 
versas maneras. Según afirma el mis- 
mo Beaty, el primer paso consiste en 
traducir el dem a emplear a un formato 
más compacto y fácil de manipular (los 
archivos dem están en formato ascii y 
pueden ser muy grandes. Además. es- 
tos ficheros pueden tener muchas post- 
bles cabeceras y especificaciones que 
hacen bastante fastidiosa y complicada 
la tarea de escribir utilidades para ellos. 
Hemos visto muy pocas utilidades para 
este tipo de archivos). 

Por estas razones Beaty comienza 
empleando una utilidad escrita en C++ 
por él mismo y que genera un fichero 
en formato Tpatch a partir del Dem ori- 
ginal. Este fichero Tpatch utiliza un 
formato inventado por el mismo Beaty 
que codifica cada dato de altitud en 2 
bytes (lo cual representa un importante 
horro en el tamaño del fichero). 

En el siguiente paso Beaty emplea 
otra utilidad que lee el archivo tpatch 
generado previamente y dibuja una 
imagen del terreno empleando un algo- 
ritmo propio. Las imágenes son vistas 
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aéreas muy similares a las que pode- 
mos ver en los mapas físicos de cual- 
quier Atlas. Según afirma el autor, esta 
utilidad genera la imagen empleando 
tres operaciones fundamentales: la im- 
terpolación. la codificación del color y 
el sombreado. En el primer paso. la i- 
terpolación puede ser necesaria si la 
imagen final a generar tiene una reso- 
lución superior a la del dem empleado 
como punto de partida. En este caso la 
utilidad generará puntos adicionales 
utilizando la mterpolación entre los 
puntos origmales. Después viene la co- 
dificación del color. Esto viene a ser al- 
go equivalente al mapa de colores de 
POV. Los picos de las montañas tienen 
un color blanco, las zonas algo más ba- 
jas del mapa se colorearán con tonos 
marrones y amarillos, y las tierras bajas 
con colores verdes. Finalmente, en el 
sombreado. se utiliza la inclinación de 
las normales de cada triángulo para de- 
terminar la cantidad de luz que recibirá 
dicha cara con respecto a una fuente de 
luz situada de forma arbitraria al 
norte del terreno. 

Para Beaty. sus imágenes tienen más 
de arte que de mapas, lo cual.queda de 
manifiesto, sobre todo en la imagen que 
ha servido de portada a este artículo y 
que Beaty creó empleando POV (el she 
de Bryan Beaty está en www.oas.om- 
ron.com/bryan/anims.html). 


Uns 


Taller Virtual 


Lnsflare. 


LnsFlare 3.0 de Nathan Kopp es probablemente la mejor utilidad 


disponible hoy día para generar luces flare con POV. Se trata de otro 


brillos de 


las toberas de 
f 


uien haya leído los : 
artículos anteriores : 


sobre Trees.mc y 


Books.mc se hará : 


una idea de cómo se 


vo “Tpas” de POV. Como ocurre con los: 
mencionados ficheros, Lnsflare se ma- | 


neja asignando valores a diversas varia- 


cosas tales como los típicos 


plosiones estelares, el brillo de 
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bles para. fmalmente, colocar una orden 
“include” que cargará el flare en nues- 


E tra escena. La cantidad de parámetros 


que se requiere para definir un flare es 


. bastante grande pero LnsFlare trae ya 
trabaja con este nue- ¿ 


definidos 20 tipos de flares distintos. 
Con lo que bastará con declarar algunas 
variables e indicar el tipo de flare para 


¿ colocarel “objeto” en nuestra escena. 


: Nuestro primer flare 
: Para situar un flare en una escena he- 


- mos de seguir una serie de pasos. En 
: primer lugar hay que indicar a LnsFla- 
E re dónde se encuentra la cámara, lo 
; cual se hará asignando a la variable 
¿_ cam_loc la misma posición que va a te- 
¿_ ner la cámara. De hecho, lo más prácti- 
É co es hacer algo como esto... 


Xx 


Luces flare para POV 


declare cam_loc = <x, y,z> 
cameraf 
location cam_loc 


Obrar así nos resultará lo más cómo- 
do, ya que sólo tendremos que cambiar 
un vector cuando vayamos a cambiar 
la posición de la cámara. Igualmente 
deberemos obrar con la vartable lookat, 
con la que indicaremos la posición ha- 
cia la que está mirando la cámara (vec- 
tor look_at), y con la variable light_loc, 
en la que señalaremos la posición de la 
fuente de luz que va a ser “flareada”. 
También hay que mdicar el vector don- 
de queda el cielo (para la cámara) en el 
identificador “sky_vect”. Esto, en una 
escena típica donde el suelo correspon- 
de al plano X-Z deberá hacerse con 
“sky_vect=y”. 

Y por último. tan sólo nos restará in- 
dicar el tipo de flare para la escena 
y colocar la sentencia include. Vea- 
mos un ejemplo: 


tídeclare flare_type =”35mm” 
tinclude “Insflare.mc” 


El array “35mm” asignado a la va- 
riable “flare_type” es el nombre 
de uno de los flares que vienen 
definidos en LnsFlare. 


Experimentos 

En tierra0.pov hay definido un flare 
del tipo “105mm” situado a 122.000 
unidades de la cámara. La imagen re- 
sultante es la de una especie de estrella 
azulada de la que parten varios rayos 
de luz. Nuestro primer experimento 
consistirá en alejar este pequeño sol su- 
mando un par de ceros a la variable 
“light_loc”. El resultado de renderizar 
esto, sin embargo. no ofrecerá cambios 
con respecto a la imagen anterior. Esto 
ocurre así porque los flares son. en rea- 
lidad, discos sobre los que se aplica una 
textura con la “luz”. El flare, en la ima- 
gen, parecerá estar en la misma posi- 


ción 3D de la fuente luminosa cuya ubi- 
cación hemos dado en “light_loc”, pero 
pronto comprenderemos que realmente 
no está en el mismo sitio ya que, sin ¡m- 
portar cuánto alejemos a la fuente, el fla- 
re seguirá teniendo el mismo tamaño. 
Esto nos vendrá muy bien porque 
podremos dedicarnos a manipular el 
aspecto del flare si que importe su ta- 
maño real ni la distancia a la que se en- 
cuentre. Tenemos que pensar en el flare 
como un efecto que se sitúa sobre la 
fuente de luz. no como un objeto nor- 
mal (es de suponer que la posición final 
del flare se calcula automáticamente a 
partir de la posición 2D de la fuente en 


imagen de Douglas Muir a la que se añade una flare 
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la imagen. Las  flares de 
Polyray se añadían una vez que la ima- 
gen estaba calculada pero LnsFlare no 
necesita hacer esto). 

Podemos comprobar esto realizando 
otro experimento: en tierral .pov se ha 
añadido al planeta Tierra en el centro 
de la imagen. La Tierra está mucho 
más cerca de la cámara que la fuente 
de luz y debería, por tanto, ocultarla. 
Pero no ocurrirá así y seguiremos vien- 
do el flare, como antes. Esto, natural- 
mente, se debe a que estamos viendo 
un efecto cuya posición se ha determi- 
nado a partir de la dirección de la fuen- 
te de luz a la que hemos atado dicho 
efecto. No estamos, insistimos, viendo 
una fuente de luz sino un efecto. 

Desde luego esto puede resultar fas- 
tidioso en ciertos casos puesto que pue- 
de interesarnos que el espectador su- 
ponga que el flare es, como parecía al 
principio, una fuente estelar. Suponga- 
mos que estamos realizando una ani- 
mación en la que precisamente hay un 
sol y un planeta. Tendríamos que tener 


cuidado de que el planeta no se imter- 
pusiera entre el sol y la cámara, ya que 
entonces quedaría claro que el flare no 
es más que un efecto. Pero, por suerte, 
Kopp pensó en esto ya en la versión 2.0 
e implementó la posibilidad de ocultar 
el flare. Veamos cómo se hace esto: an- 
te todo hay que decirle a LnsFlare dón- 
de está el mundo que va a ocultar al fla- 
re y el radio del planeta: 


tdeclare planet_loc = <X.Y.Z> 
declare planet_rad = Rmundo 


El vector indicado en planet_loc tie- 
ne la posición del planeta y “Rmundo” 
es el radio del mismo. También habre- 
mos de indicar el radio de la fuente 
asociada al flare con... 


tideclare light_rad = Rluz 


Si hecho esto renderizamos de nuevo 
veremos que POV imprime un mensaje 
diciendo que la fuente de luz queda de- 
trás de la cámara o detrás de un planeta. 


y que el flare no se ha creado. Sin em- 
bargo, st alteramos el valor de la varia- 
ble light_loc de tal modo que la fuente 
no quede oculta por el planeta aunque 
sí cerca de algún punto de su perfil, en- 
tonces POV imprimirá un mensaje di- 
ciendo que será visible un porcentaje 
del flare. De esto parece deducirse 
(aunque no hemos realizado la prueba) 
que podríamos realizar una estupenda 
animación en la que un sol apareciera 
de detrás de un planeta. 

Kopp también ha previsto el poder 
hacer lo mismo con un plano, de ma- 
nera que podamos representar una 
puesta de sol. Para ello emplearemos 
las varrables siguientes; 


tideclare plane_loc =<x,y.z> 
tdeclare plane_norm = <x,y,z> 


“Plane_loc” guarda las coordenadas 
del plano y “plane_norm” su normal 
(Nota: por ahora solamente puede es- 
pecificarse un planeta o un plano que 
oculten al flare). 


Manipular flares 

Los flares de este “ipas” están com- 
puestos por partes cuyas características 
podemos alterar cambiando los valores 
dados por defecto. En primer lugar te- 
nemos el flare inicial o primario, Éste 
consiste en un brillo central con el que 
el espectador identificará a la fuente. 
Luego. extendiéndose a partir de este 
flare imicial, tenemos una zona semi- 
transparente (glow) cuyo resplandor va 
decreciendo a medida que nos aleja- 
mos del flare primario. Esta zona pue- 
de extenderse mcluso más allá del ani- 
llo. Después tenemos un anillo (ring) 
que engloba al flare micial (y normal- 
mente también al glow). Además, nor- 


malmente suele haber unos destellos 
(sparkles) que parten del flare primario 
y, opcionalmente, unas bandas (stre- 
aks) que atraviesan el flare inicial (y 
que suelen asociarse a las explosiones 
estelares o a los brillos de los focos). 
Aquí acaba lo que podemos consi- 
derar como la parte principal del fare. 
Luego siguen otros flares secundarios 
a los que llamaremos flare 
spots y flare dots. Ambos 
se dibujan formando una 
línea que cruza el flare 
inicial (en light_loc) y el 
punto central de la ima- 
gen (definido en lookat). 
Los flare spots son los 
empleados por defecto. 
Tienden a ser más trans- 
parentes en el interior que 
en sus bordes y por ello 
son llamados a veces ring 
spots. En los otros sucede 
exactamente a la versa y 
también se distinguen por 
ser (por defecto) más pe- 
queños que sus hermanos. 
Veamos ahora cómo funciona todo 
esto. Kopp ha meluido en el archivo la 
definición de una vemtena de flares que 
nos servirán para muchos casos dife- 
rentes. Ya hemos visto cómo usar estas 
flares predefinidas pero, en la práctica, 
es casi seguro que el usuario mtentará 
crear enseguida sus propias flares em- 
pezando. quizá. por especificar un tipo 
concreto para realizar experimentos so- 
bre él. ¡Craso error! La sorpresa del 
pov-adepto resultará mayúscula al 
principio, cuando se percate de que sus 
cambios en las variables de tamaño, co- 
lor y otras, no tienen el menor efecto. 
No obstante, la explicación es muy 
sencilla: Kopp no ha empleado las sen- 
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tencias Hifndef de la manera que po- 


dríamos suponer, colocando Hifndefs 
en todas las variables de cada tipo de 
flare. De haberlo hecho así podriamos 
declarar las variables del flare, y luego 
mvocar al tipo deseado con la seguri- 
dad de que los cambios tendrían efecto. 
Esto sería lo más fácil pero podemos 
olvidarnos de ello. La única manera de 
conseguir cambios en un flare predefi- 
nido es, pues, cambiar las variables co- 
rrespondientes en LnsFlare.mc. 

Pero hay una excepción a esto. Si 
eliminamos la declaración de la varia- 
ble “flare_type”, LnsFlare entenderá 
que queremos emplear el flare por de- 
fecto, el cual sí utiliza Hifndefs en to- 
das sus variables. La solución pasará 


pues por no emplear 


flare_type y copiar los de- 
clares del flare sobre el 
que pretendamos experi 
mentar. A menos, claro es- 
tá, que pretendamos em- 
pezar desde cero o alterar 
al propio flare por defecto. 


Variables 
de control 
del flare primario 
Sabido esto ya estamos en condicio- 
nes de empezar a estudiar las variables 
de LnsFlare.inc. En primer lugar tene- 
mos las que afectan a las dimensiones 
del Flare. Estas son source_size, 
glow_size, ring_size y ring_width. La 
primera afecta a las dimensiones del 
flare primario y su valor es, por defec- 
to. de 0.02. Las siguientes son, respec- 
tivamente, las dimensiones del glow. 
del anillo y del ancho del anillo. Es im- 
portante aclarar que estos valores son 
relativos al tamaño global de la pantalla 
y que es por esta razón por la que el fla- 
re no crece ni disminuye de tamaño 
cuando la cámara o la fuente se alejan. 
Sólo hay una excepción para esto: si 
cambiamos el valor “telescópico” de la 


de 


sentencia “direction” de la cámara (que 
se emplea para hacer zooms), entonces 
el tamaño del flare sí quedará afectado. 

Ahora veamos las variables que con- 
trolan el color. Las de control directo 
son source_color, glow_color y 
ring_color. Como ya imaginará el lec- 
tor, controlan respectivamente el color 
del flare primario. del glow y del anillo. 
Otras variables como source_bright y 
glow_bright son factores que se em- 
plean para multiplicar el brillo del flare 
primario y su glow, controlando así su 
máximo nivel de brillo. Sin embargo, 
estas últimas variables no produ- 
cirán efectos visibles si el co- 
lor asignado ya estaba a su 
máximo valor de lumi- 
nosidad. Otras varia- 
bles que afectan al 
flare son las que 
controlan el nivel 
de translucencia. 
Estas son sour- 
ce_tr. glow_tr y 
ring_tr que afec- 
tan respectiva- 
mente al nivel 
mínimo de trans- 
lucencia del flare 
primario, del glow y 
del anillo. 


Destellos (Sparkles) 
Los destellos son brazos ra- 
diales que parten del flare primario. 
Los hay de dos grupos: en el primero 
los brazos son más largos que los del 
segundo grupo, siendo los destellos de 
este último más numerosos que los del 
primero. La longitud de estos brazos se 
define en las variables star_size (primer 
grupo) y star2_size (segundo grupo). 
El número de destellos se indicará en 
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num_arms y num_arms2, el ancho de 


los brazos se especificará en star_width : 


y star2_width y su color en star_color. 
Otras variables importantes son star_tr, 
que controla el nivel mínimo de trans- 
lucencia, star_seed, que guarda un va- 
lor de semilla para la aleatoriedad en la 
colocación de los destellos, y 
Crisp_star, que causa el que los deste- 
llos del primer grupo tengan bordes de- 
fiidos (ver el flare “concert”). Por su- 


puesto podemos 


El planeta tapa parcialmente al flare 


eliminar 


los destellos poniendo num_arms y 
num_arms2 a cero. 


Flare spots y dots 
Las características de los flares se- 
cundarios son controladas mediante 


una serie de variables que describire- 
mos a continuación: Spot_size contro- 
lará el tamaño standard que se aplicará 
para estos flares y spot_color guardará 
su color normal (luego veremos el por- 
qué de la palabra normal”). Spot_tr 
guardará la translucencia mínima del 
spot y num_spots indicará al “ipas” el 
número de flares secundarios que se di- 
bujarán a cada lado del flare primario. 
La separación entre los flares depende- 
rá en principio de la distancia entre el 
flare primario y la posición observada 
pero podemos influir sobre dicha se- 
paración con un par de variables; 
spot_dist y spot_dist_pwr. 
La primera es un factor 
pero, en el momento de 
escribir estas líneas. 
no comprendemos 
aún su funciona- 
miento exacto. 
En cuanto a la 
segunda, deter- 
mina si el creci- 
miento de las 
distancias de los 
flares secunda- 
rios con respecto 
al primero es lineal 
(valor 1) o cuadráti- 
co (valor 2). Otra va- 
riable  ¡mteresante es 
skip_spots con la que indi- 
caremos el número de spots que 
pueden omitirse (y que serán los 
más cercanos al flare primario). 

Ahora vamos con un detalle muy in- 
teresante. Las variables descritas hasta 
ahora afectarán por ¡igual a todos los 
spots con lo que el resultado final será 
excesivamente uniforme. Para reme- 
diar esto y dar algo de alegría al con- 
Junto disponemos de algunas variables 


que introducirán un factor de aleatorie- 
dad enlos flares secundarios. Estas va- 
riables son spot_size_rand. spot_co- 
lor_rand, spot_dist_rand y spot_seed. 
Los valores (de O a 1) que demos a es- 
tas variables se entenderán como un 
porcentaje de desviación con respecto a 
los valores “normales” definidos por 
las variables de tamaño, color y distan- 
cia que ya hemos visto. Por ejemplo, 
un valor de 0.2 en spot_size_rand im- 
plicará que el tamaño de los flares se- 
cundarios oscilará entre un 80% y un 
120% con respecto al definido en 
spot_size. Spot_seed es, por supuesto, 
la semilla con la que alimentaremos al 
generador pseudoaleatorio. 

¿Y cuándo se dibujan los flare dots? 
Bien, para eso está la variable amada 
percent.dots, donde indicaremos un va- 
lor de O a 1 con el porcentaje de flares 
secundarios que deseamos que sean 
flares dot. Estos flares tienen su propio 
grupo de variables; dot_size, dot_color 
y dot_tr, cuyo significado ya habrá adi- 
vinado el lector. 

¡Pero aún hay más! A partir de la 
versión 2.1, Kopp añadió la posibilidad 
de que los flares se visualizaran como 
hexágonos. Como anteriormente, para 
determinar el porcentaje de flares que 
deberán verse así, existe una variable 
determinada; percent_hex. Las carac- 
terísticas de estos flares serán contro- 
ladas con las variables que empiezan 
con la palabra spot. 


Bandas de luz (flare streaks) 
Las bandas de luz son una caracte- 
rística que se encuentra desactivada por 
defecto. Estas bandas suelen ser hori- 
zontales o verticales y pueden em- 
plearse para producir la imagen de una 
explosión estelar (ver flare space2) o 
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del foco típico de un campo de fútbol 
(flare sports). Las variables que contro- 
lan su funcionamiento son: 
streak_a_size, que controla el radio del 
flare, streak_a_color, con el que se es- 
pecifica el color del borde de la banda. 
streak_a_center_color, que indicará el 
color del centro de la banda, streak_tr, 
que se usa para indicar la translucencia 
mínima de la banda, streak_a_scale, en 
el que guardaremos un vector para in- 
dicar la escala de la banda en los ejes X 
e Y, y streak_a_rotate, que se empleará 
para rotar la banda. 

El lector habrá observado el em- 
pleo de una *a” en todas estas varia- 
bles. Esto quiere decir que dichas ór- 
denes se limitan a la banda “A” y que 
existe una segunda banda llamada “B” 
para la que hay otro juego de varia- 
bles que emplean la “b”. Esto pode- 
mos comprobarlo examinando las lí- 
neas del flare sports, en el que se 
emplean las dos bandas y donde éstas 
se giran 45 grados. 


Variables de uso general 
El tamaño global de cualquier flare 
entero puede controlarse con la varia- 
ble flare_scale_factor. cuyo valor por 
defecto es de 1. Si ponemos un valor 
de 2 en esta variable el tamaño del flare 
se doblará y si colocamos un valor 0.5. 
se dividirá por 2. Flare_rotate se em- 
plea para rotar el flare. Flare_bright- 
ness (que guarda valores normalmente 
superiores a 1) se utiliza para ajustar el 
brillo global del flare y suele usarse 
cuando el flare ha quedado demasiado 
oscuro para la imagen. 
Main_flare_scale se utiliza para 
controlar la escala del flare primario y 
de sus brillos y glow. Además podemos 
hacer que la escala a ordenar no sea 
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idéntica en los dos ejes. con lo cual 
conseguiremos un interesante efecto de 
achatamiento similar al logrado en el 
flare space2. 


Notas y trucos 

Lo explicado hasta aquí debería ser 
suficiente para que los povmaníacos 
hagan sus propias escenas con este 
magnífico “ipas”. Únicamente hay que 
recordar un par de cosas: 

1) Algunas variables precisan va- 
lores que oscilan entre O y 1 y otras no. 
Si lo que hacéis no funciona echad un 
vistazo a las flares predefinidas. Es la 
mejor manera de asegurarse del tipo de 
entrada que precisa cada variable. 

2) Podemos colocar más de un fla- 
re en la escena. Para ello bastará con 
colocar otra sentencia con un nuevo va- 
lor para light_loc y. por supuesto. con 
colocar otro include para LnsFlare. 

3) El flare que haya sido definido 
seguirá a la fuente a la que esté atado 
en una animación pero, en algunos ca- 
sos. puede ser necesario emplear la 
sentencia “vrotate” del lenguaje escé- 
nico de POV. 

4) Si hay problemas con espejos 
deberéis incrementar el valor de 
fmax_trace_level. 

5) Podéis encontrar próximas ver- 
siones de LnsFlare en el “site” de 
Nathan Kopp cuya visita os recomen- 
Está 
http://www.grfn.org/-nkopp. En sus 


damos, en la dirección 
páginas, Kopp exhibe unas modifica- 
ciones de viejas obras de Douglas Muir 
y Dan Farmer.(hemos duplicado la de 
Muir añadiendo simplemente una fla- 
re, como hizo el mismo Kopp). 

6) Los flares no funcionarán si se 


emplea algún tipo especial de cámara. 
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Espacial 


Este artículo se aparta un tanto de todo lo que es habitual en estas 


páginas pero creemos que por una vez valdrá la pena hacer una 
excepción. Todo empezó bastante inocentemente, buscando unos 
bitmaps planetarios por Internet, y acabó con un vistazo al arte espacial 
renderizado de la Nasa, una exploración marciana con MapMaker, y un 
recorrido por todo el sistema solar de la mano del simulador de la Jet 


Propulsion Laboratory. 


Un sl 


ste artículo bien po- 

dría haber tenido un 

título diferente co- 

mo por ejemplo; 

“Porque amo a In- 

ternet” o algo pare- 
cido. Sí, en efecto. Tenemos por fin una 
conexión propia y no podemos com- 
prender cómo pudimos vivir antes sin 
ella. Sin duda ya estaréis hartos de oir 
frases como esta, pero la verdad es que 
llega un momento en que toda esa pe- 
sada palabrería quiere decir algo: ren- 
dermaníacos; la Red es algo maravillo- 
so. Sólo el navegar, el explorar, ya es 
algo fascinante. Uno salta de un sitio a 
otro, la mayoría de las veces sin hallar 
nada útil, pero otras encontrando la 
perla que hace que todo valga la pena. 
Y además, la perla encontrada suele te- 
ner links que también tienen su interés. 


Dónde encontrar 
bitmaps planetarios 
El nuevo navegante ya no recuerda 
cómo encontró el Web de Thomas 
Constantine. El caso es que una de sus 
páginas. cuya dirección es... 
www.lancs.ac.uk./postgrad/tho- 
mascl/render/maps.htm 


..-pronto demostró ser muy intere- 
sante. Allí había un índice de mapas de 
planetas. Estaban la Tierra, Marte. Sa- 
turno, Urano, etc. Al pinchar en el link 
de “Earth”, apareció una página con 
datos globales sobre nuestro mundo y 
también una ventana que exhibía un 
bitmap en proyección cilíndrica simple 
de la Tierra. Al pinchar sobre ella se 
cargó una preciosa imagen jpg con una 
vista de toda la corteza terrestre y de su 
atmósfera y ésta ha sido la textura que 
hemos empleado (en las pruebas de 
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LnsFlare) para el planeta. Tierra. ¿Có- 
mo? ¿Que hay alguien que no sabe lo 
que es un bitmap de proyección cilín- 
drica? Pues se trata de una textura que 
emplearemos para recubrir a objetos de 
forma cilíndrica o esférica. Las si- 
guientes son las líneas con las que pue- 
de crearse a la “Tierra” desde POV: 
sphere ( pos_tierra, radio 
pigment ( 
image_map( tga “earth.tga” 
map type 1] 
! 
rotate y*-50 
) 


Desde luego la cosa es bien sencilla. 
Basta con crear una esfera y recubrirla 
con nuestro bitmap. Por si alguien aún 
no lo sabe, tendremos que emplear una 
proyección esférica (por defecto la pro- 
yección que realiza POV es plana y se 
extiende a lo largo del plano X-Y. Si 
queremos efectuar un mapeado esféri- 
co daremos el valor 1 a map_type). 
Usando la aplicación esférica. la tex- 
tura indicada se mapeará adecuada- 
mente sobre la esfera que hace las ve- 
ces de planeta. El bitmap se enrollará 
sobre la esfera de manera que su bor- 
de superior quede 
en el polo norte y 
el inferior en el 
polo sur. La tex- 
tura  recubrirá 
completamente a 
la esfera una úni- 
ca vez sin que 
importe el tama- 
ño que ésta pueda 
tener (la palabra 
“once” no funcio- 
na con este tipo 


Pero ahora volvamos con la navega- 


ción: después de retornar al Índice, en- 
contramos mapas similares que pueden 
ser usados para crear planetas con el 
aspecto de Marte, Júpiter, etc. El mapa 
de la Tierra es el producto resultante de 
miles de fotografías tomadas por una 
serie de satélites y por tanto es muy 
preciso. Otros, como el de Júpiter por 
ejemplo, han requerido bastante es- 
fuerzo infográfico y artístico (emplean- 
do productos como Photoshop y otros) 
para conseguir el resultado final que 
podéis ver en el CD-ROM. En cual- 
quier caso estos mapas —que podéis en- 
contrar en el CD-ROM- pueden ser 
utilizados en simulaciones de viajes 
por el sistema solar o en escenas artís- 
ticas, y pueden ser empleados por cual- 
quier programa 3D y no sólo por POV. 


Arte planetario 

Después de “bajarnos” unas cuantas 
texturas de este tipo, retornamos al 
principio de la página y leímos que mu- 
chos de los mapas que podían encon- 


trarse antes en el Web de Thomas ya no 


de proyección). Po 


E 


í Una vista de Saturno desde uno de sus satélites 


y 


Bitmap para aplicación esférica 


estaban, pero que había otras nuevas 
versiones en la página de un tal David 
Seal. Unas líneas más abajo se indicaba 
que David trabajaba en el Jet Propul- 
sion Lab (JPL) y que era responsable 
de gran parte del trabajo artístico de la 
Nasa. ¿Trabajo artístico de la Nasa? Y 
se añadía que por esa razón los mapas 
de David eran mucho más grandes y 
detallados que los del propio Thomas... 
Después de pinchar en el link de Da- 
vid se tomó nota de la dirección 
siguiente... 
http://samadhi.jpl.nasa.gov/txmp 


Allí, aparte de muchos más mapas, 
hay mucha información interesante. 
Eliminando el directorio txmp de la di- 
rección accederemos a una página don- 
de hay enlaces a muchos lugares de in- 
terés. Comenzaremos comentando la 
existencia del “Nasa Mission Artwork” 
(en http://samadhi.¡pl.nasa.gov/art). 
Aquí pueden verse preciosas escenas 
renderizadas de sondas espaciales via- 
jando por distintos puntos del sistema 
solar, En cada una de estas Imágenes, se 
explica el punto de la misión que repre- 
senta la escena, las maniobras que Jle- 
varon (o llevaran) allí a la nave, etc. Es- 
tas imágenes (o animaciones porque 
también las hay) fueron hechas con mul- 
titud de herramientas sobre plataformas 
SPARC y SGI (y parece ser que la más 
importante es SPACE; un conjunto de 
programas diseñados para simular tra- 
yectorias de naves espaciales y que la 
nasa emplea para crear simulaciones de 
misiones en fase de proyecto). 

Otro lugar interesante es el “Solar 
System Surfaces”, donde encontrare- 
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El Solar System Simulator en acción 


mos renders de tipo artístico de diver- 
sas superficies de diferentes objetos del 
sistema solar (el sol, asteroides, plane- 
tas...) Algunas de estas escenas (que po- 
déis admirar en el CD-ROM) son muy 
bellas. La dirección de esta página es... 
http://samadhi.¡pl.nasa.gov/surfaces 


Pero continuenos con nuestro peri- 
plo. Otro enlace interesante de la pági- 
na base es el “Spacecraft Models”, en 
el directorio models, donde el infogra- 
fista hallará una lista de modelos 3D de 
las sondas de la Nasa (el problema es 
que hay muy pocas en formato dxf). 

Y finalmente. y ya para acabar con 
este sitio, tenemos el “Solar System Si- 


mulator”. Parece ser que en junio del 
97 David Seal terminó de adaptar el 
software de Space y lo conectó al 
World Wide Web. Este nuevo software 


viene a ser un completo simulador del 


sistema solar, ya que puede renderizar 
cualquier punto del mismo teniendo en 
cuenta la posición del observador, el 
punto hacia el que mira, la fecha, el 
campo de vista, etc. Las texturas em- 
pleadas en los planetas y otros cuerpos 
han sido obtenidas de diversas colec- 
ciones de fotos tomadas por sondas es- 
paciales y muchas de ellas pueden ser 
encontradas en la página de mapas que 
hemos comentado anteriormente. Se- 
gún se rumorea, este software podría 
estar disponible en un futuro próximo 
aunque, claro está, no lo cataremos los 
infografistas de a pie (¿alguien tiene 
aquí una SPARC?) 


Viaje fotográfico 
por los planetas 

Perdido entre las páginas anteriores 
hay un link de un lugar llamado “Na- 
sa's Planetary Photojournal”. Se trata 
de una enorme colección de fotografías 
tomadas por sondas espaciales y que 
los aficionados a la astronomía podrán 
bajarse tranquilamente, ya que han sido 
cedidas al uso público. Hay que preci- 
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sar que se trata de fotografías y no de 


imágenes retocadas y preparadas para 
ser empleadas intográficamente. El 
usuario podrá solicitar las fotos direc- 
tamente (si conoce la codificación em- 
pleada) o podrá ir examinando las fotos 
de una sonda determinada, tras lo cual 
podrá bajarla a su modesto PC. Hay 
que advertir, sin embargo, que muchas 
de estas fotos tienen una resolución 
grande o muy grande y que el ciber- 
nauta tendrá que tener cuidado, so pena 
de perder el tiempo mirando una enor- 
me foto de la luna u otro cuerpo duran- 
te más tiempo del que querríamos, Esta 
colección, que crece diariamente. tie- 


ne, en estos momentos de es- 
cribir estas líneas, algo 
menos de 700 fotos y su 
dirección es: 
http://photojournal.jpl. 
hasa.gov | 


Mapas marcianos 
a medida 

Otro lugar a visitar ¡nexcusa- 
blemente es el Charlotte"s Web Server. 
desde el que podremos acceder a mu- 
chos lugares de interés. Su dirección es 
“http://www-pdsimage.¡pl.nasa.eov” y 
desde allí podreo, os saltar al “Solar 
System Visualization Proyect” (que re- 
sultó ser horriblemente lento en las 
pruebas) o al “Planetary Data System 
Imaging.Node”. Este ultimo parece ser 
un sistema que mantiene y distribuye 
los archivos de fotos y datos de la Na- 
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ceder a ellas vía Internet de una manera 
sumamente atractiva: pinchando en un 
mapa global de Marte pincharemos en 
la zona que nos interese. Entonces, tras 
una corta espera, MapMaker compon- 
drá un mapa con las fotos de la zona y 
nos lo enviará. Podremos entonces se- 
sa, a fin de que la comunidad científica guir haciendo ampliaciones de la mis- 
tenga un fácil acceso a ellos. A través ma manera o bien desplazarnos por la 
del “Node” puede accederse a un siste- superficie marciana con las flechas de 
ma de ficheros almacenados en CD- movimiento. Naturalmente Hegará un 
ROM por el que los expertos podrán momento en que. si seguimos amplian- 
acceder a datos de misiones históricas do y ampliando, Hegaremos al límite de 
que, según parece, estaban a punto de resolución de las fotos y no será posi- 
ble continuar con el zoom (el uso de 
MapMaker es muy divertido. Pensad- 


lo: estamos viajando por Marte). 


perderse al no haber antes un sitio es- 
pecializado para ellas. Así pues mu- 
chas de las imágenes almacenadas (hay 
algunas excepciones) podrán ser acce- La comodidad que proporciona Map- 
didas a traves del software de extrac- Maker al usuario es enorme (y. además. 
ción de datos del mismo Web, cuya di- estos mapas sí pueden ser empleados en 


rección de Internet es: escenas sintéticas). Además, según se 


http://www-pdsimage.jplnasa.gov/PDS dice, es posible que en un futuro próxi- 


La cantidad de información almace- mo MapMaker soporte a otros cuerpos 
nada aquí es enorme. Por po- celestes como la Luna o Venus. 
ner un ejemplo, solamente 

Todo tiene un final 


Durante este viaje por la Red halla- 


las fotos accesibles bajo 
el epígrafe de las son- 
das Viking ya son mos texturas. fotos, animaciones, faqs, 
50.000. Y hablando de 


las sondas Viking. des- 


etc. El caudal de datos (y de siglas de 
organizaciones que los mantenían) no 
de la dirección anterior parecía tener fin. También encontramos 
podremos acceder al “Mars otros “sites” de arte espacial hecho por 


Explorer” un programa por el ¿usuarios (muchos de ellos de POV) e 


¿incluso naves espaciales para los más 
A diversos programas (incluyendo a Ima- 
gine y POV) pero ya hablaremos de 
ello en otro momento. 

En cuanto a los bitmaps planetarios, 
estos están en formato jpg por lo que 
tendréis que convertirlos a TGA con al- 
guna utilidad ps o Photos- 
hop antes de emp y 
A 


que el usuario podrá crear su propio 
mapa de la superficie marciana esco- 
giendo su propio factor de zoom, tama-  ¿ 
ño del mapa y sistema de proyección. E 
Los mapas se confeccio rán gracias a 
un software amado MapMaker que 
trabajará sobre las fotos de las misio- 
nes Viking para crear el mapa que de- 
seemos. Segun parece las fotos están 
almacenadas en un sistema de CD- 
ROM y el programa nos permitirá ac- 
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El Foro del Lector 


Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en la segunda página de POmanía, o vía e-mail a rendermania.pcmaniaO hobbypress.es 


Hoy, 3D Studio 


Este mes -y salvo excepciones- casi todos los trabajos recibidos tienen 
en común el haber sido creados con «3D Studio». Sin embargo, esta es la 
única coincidencia, ya que en todo lo demás la diversidad es la norma en 
estas páginas en las que podremos ver soldados medievales, Mechs de 


combate, animaciones varias y otros trabajos de interés. 


Una de las mayores recompensas de nuestro trabajo consiste en leer las car- 
tas de lectores que nos envían ánimos, elogios, críticas o. simplemente, el 
mensaje de que nuestros artículos han servido de algo. Misivas como la de 
—que podéis encontrar en el foro— caen en este apar- 
tado, Julián, ya un viejo conocido de Rendermanía, asegura haberse empo- 
llado la serie de artículos dedicados a Imagine y ahora recibimos el fruto de 
su trabajo: el temible battlemech de la 
serie 201. un mech de combate dise- 
ñado por Julián. completamente arti- 
culado y dispuesto para la lucha (que 
podreis encontrar en el CD-ROM). 
Julián nos pide una crítica de su mech 
pero la verdad es que ésta se nos hace 


muy difícil porque lo cierto es que nos 
ha gustado todo, incluso la textura. 
Los puntos de articulación para el 201 
parecen correctamente dispuestos, la 
forma es interesante, el pie es muy 
majo y Julián de- 
muestra en su carta 
un buen conocimien- 
to de Imagine. Como 
puede verse en una de 
tus escenas. tu mech 
es mucho más pesado 
que el nuestro. ¿No 
resultará algo lento a 


pesar de su nuevo reactor Pullman 1.6? 

Julián también pide la Opinión de otros rendermaníacos sobre su trabajo y, como 
el movimiento se demuestra andando, él hace lo propio con algunos viejos cono- 
cidos como Díaz, Sendin, Torres y otros. ¡Enhorabuena por tus Imagine-criatu- 


ras! (Naturalmente esperamos las próximas, ya sean de POV o Imagine). 
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Imagen creada por Antonio Abenza. 
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La primera animación de ¡ era 
un recorrido casi completo por una casa. 
Desdichadamente dicha animación ocupaba 
unos 62 Megas y por esa razón Carles ha 
debido contentarse con enviarnos otra que 


nos 
envia uno de sus primeros 
trabajos realizado con «3D 
Studio». Se trata de un mo- 
delo con el escudo de su 
equipo de fútbol favorito; el 
Córdoba. Felipe incluye ade- 
más una sugerencia en su 
carta solicitando un curso de 
«3D Studio». Bien, por el 
momento no hay nada pre- 
visto sobre ello pero nunca 
hay que descartar ninguna 
posibilidad... 


sólo tlene unos 
2 Megas. (Por 
cierto, nuestro 
más sentido 
pésame por los 
cuelgues que 
se producen en 
tu ordenador). 
Esta  anima- 
ción está reali- 
zada con «3D 
Studio 4». 


O 
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4 l nos envía 


también sus primeros trabajos hechos ] 


con el programa <3D Studio 4». Algu- 
nos de ellos —como el taller— tienen más 
merito y trabajo del que parece (el ca- 
ble del soldador, las tenazas, etc) y por 
ello te enviamos la oportuna felicita- 
ción. Tan sólo te diremos que deberías 
haber enviado una malla o un texto ex- 
plicativo que ayudara a certificar la au- 
toría de tus imágenes. 


Jose Miguel Dominguez 
Montesinos es otro render- 
maníaco que también envía 
sus primeros trabajos con 
«3D Studio 4». José Miguel 
no ha enviado tampoco ni ma- 
llas ni excesivos datos acerca 
del proceso de creación de sus 
trabajos y por ello le envia- 
mos el oportuno tirón de ore- 
jas. José Miguel apunta en su 
carta algunas preguntillas: 

1) ¿Cómo hacer que las 
superficies de «3D Studio» no 
queden tan perfectas? Como 
siempre hay diversos caminos 
pero casi todos pasan por em- 
pollarse bien el Materials edi- 
tor. Lo más sencillo es aplicar 
algún bitmap con apariencia 
de metal corroído y eliminar 
los brillos de las superficies, Otro sistema menos utilizado 
es emplear algún Ipas de fractalización que desordene al 
azar (en un pequeño factor) los vértices. 

2) ¿Dónde pueden encontrarse en Internet Ipas para «3D 
Studio»? Esto no es fácil ya que la inmensa mayoría de los 
Ipas son de pago y no se distribuyen libremente (salvo en 
versiones recortadas). Prueba a mirar cada cierto tiempo en 
el Web de Avalon. donde también podrás hallar objetos, 
texturas. Informaciones diversas, etc. (En 
http://avalon.viewpoint.com o a través de www.view- 
point.com). Otro lugar interesante es el 3dcafe en 
www.3dcafe.com 

3) ¿Que si se pueden conseguir imágenes de buena cali- 
dad con POV? Dios mío... 


Hector de la Fuente Pita nos envía, entre otros modelos, un soldado medieval creado con 
«3D Studio 3». Según afirma Héctor, casi todas las piezas del modelo —cuya malla podéis en- 
contrar en el CD-ROM- fueron construidas con la opción Fit a partir de formas creadas desde 
el 2d Shaper. Para este modelo Héctor solicita una ¿severa? crítica. Bueno, las proporciones 
generales del soldado son correctas y éste merece todo el reconocimiento que debe darse a 
cualquier modelo antropomórfico aceptablemente resultón. Quizá hubieras debido añadirle al- 
gunas piezas sueltas (un faldellín, un peto, etc.) que hicieran las funciones de armadura ligera 
y haber aplicado al modelo actual una textura que recordara a las típicas cotas de malla de la 
época. Las manos tampoco son muy buenas pero es dificilísimo hacer unas manos aceptables 
con técnicas normales. : 

El soldado llegó con algo de retraso para la batalla (que de todos modos se quedó en escaramuza por falta de memoria) pero es posible 
que cuando haya orcos, este modelo pueda ser aprovechado (al igual que otros). 

En cuanto a tu sugerencia, todos los lectores de PCmanía pueden formar sus propias colecciones de objetos a partir del material que se 
va publicando aquí todos los meses. Lo único que queda es sugerir temas, lo cual ya está previsto para el asunto de las portadas. Por lo de- 
más la organización de los modelos según los temas podría ser algo problemática ya que requeriría un tiempo del que ahora carecemos (y 
además habría que escribir sobre cosas que ya se habrían comentado en números previos, lo cual no nos parece un ahorro de espacio). 
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nos envía algunas imágenes 
creadas con «3D Studio 4» con las que pasa a formar parte 
de la cada vez más extensa lista de rendermaníacos info- 
gráficamente activos. Pedro solicita alguna guía para me- 
jorar, y desde aquí te damos un consejo muy sencillo: prac- 
tica mucho el modelado y no emplees tantísimos polígonos 
para algo que puede representarse igual con mallas mucho 
menos densas (basta con ver la columna del templo). En 
cuanto a tus sugerencias... 

1) Eo de incluir texturas de libre distribución es una 
buena idea pero no hay tantas (de calidad) como imaginas. 
¿Qué te parecen las texturas planetarias que hemos enseña- 
do en el presente número? 

2) En cuanto al debate, sería muy difícil evitar que 
acabara reducido a una mera publicación de opiniones (¡no 
puede haber tiempo real!). En algún momento han surgido 
temas que provocaban el envío de opiniones por parte de 
los lectores (para eso está también 
el foro) pero no creemos conve- 
niente provocar debates porque sí. 
Lo ideal para cualquier renderma- 
níaco es practicar, crear cosas. e 
intercambiar conocimientos rela- 
cionados con cosas concretas. 

En cuanto a tus preguntas, la 
utilidad 3ds2pov puede convertir 
ficheros de 3D Studio a POV con 
casi total perfección, ya que se tra- 
ducen modelos, colores, posición 
de las luces y de la cámara, etc. La 
imagen generada en POV será prácticamente idéntica a la 
creada por 3D Studio salvo por lo referente a los bitmaps, si 
los hay. Lo contrario (POV a 3D Studio) no es posible en la 
inmensa mayoría de los casos debido a que las primitivas de 
POV no se construyen con polígonos. Y para cuestiones ar- 
quitectónicas preferimos POV a 3D Studio (tu otra pregun- 
ta), aunque esto siempre es algo muy subjetivo. 


El Foro del Lector 


alias «3d reality» ha en- 
viado varias animaciones creadas con «3D 
Studio 4». Pero, desgraciadamente, uno de 
los ficheros del paquete (el reality.a03) lle- 
gó estropeado y sólo fue posible salvar a 
mago.avi. En esta animación, Borja ha 
creado unas secuencias de gran realismo 
empleando el magnífico mago creado por 
Juan Carlos Jiménez Méndez. En la pelí- 
cula el mago corre, se detiene, prepara una 
bola de energía mágica y la lanza para, fi- 
nalmente, ejecutar un saludo ritual. Los re- 
sultados son sencillamente magníficos y en 
ellos se aprecia que, salvo en unos minús- 
culos detalles, el movimiento del personaje 
es perfecto. El mago no sufre prácticamen- 
te deslizamientos al correr (fijaos en la to- 


ma lateral) y pueden apreciarse bien los 
cambios de altura debidos a este ejercicio, 
Lo único que desentona (en cuanto a nivel 
de realismo) son los movimientos de los 
pies del personaje cuando éste ya se ha de- 
tenido y está preparando y lanzando la bo- 
la mágica (porque se producen unos desli- 
zamientos bastante raros). Pero, salvo este 
pequeño detalle, la animación es extraor- 
dinaria. ¡Enhorabuena amigo Borja! 


Por varias razones tenemos que enviar un tirón de orejas a nues- 
tro amigo Este lector nos ha enviado su primer traba- 
Jo (con «Imagine 3.0») basado en un juego llamado Ballz. Pero, 
Oriol no ha incluido ni un solo render del modelo. razón por la cual 
no hay aquí ninguna foto del mismo. Además, tampoco diste la ex- 
tensión adecuada (obj) al archivo, con lo cual al principio lo toma- 
mos por una ¡magen en algún formato raro, 


